The game is a multiplayer online strategy game inspired by Tribal Wars, where players build villages, train armies, and compete for dominance in world. The system must support thousands of concurrent players, offer real-time interactions, and be scalable for future expansions.
Features:
| Goal | Motivation/description |
|---|---|
| Security | Protect against cheating, unauthorized access, and data breaches. |
| Reliability | System ensuring minimal downtime during server maintenance. |
| Role/Name | Expectations |
|---|---|
| Players | Expect engaging gameplay and fair rules. |
| Developers | Need a maintainable and extensible codebase for future updates. |
| Game Administrators | Tools to manage game worlds, monitor player activity, and enforce rules. |
| Constraint | Description |
|---|---|
| Database Technology | Integration with NoSQL solutions (e.g., MongoDB) for high-performance tasks like caching and leaderboards. |
| Observability | System must send metrics for further analysis |
| Constraint | Description |
|---|
| Constraint | Description |
|---|---|
| Architecture documentation | Terminology and structure according to the arc42 template. |
| Java applications | Application written in Ports & Adapters (aka Hexagonal) architecture |
| Goal | Description |
|---|---|
| Security | Implement OAuth2 for secure player authentication |
| Development Strategy | Use GitHub Actions to automate testing, build and deployment pipelines. |
| Deployment Strategy | Staging Environment or testing before pushing to production. |
Diagram from 3.1. section displaying all systems:
| System | Description |
|---|---|
| Game system | Main system responsible for gameplay. |
| Identity and Access Management (IAM) system | System responsible for authentication and user management. |
| Observability System | System responsible for collecting telemetry signals: traces, metrics and logs. |
The system architecture consists of three main components: the frontend, backend, and supporting infrastructure.
| System or components | Description |
|---|---|
| Frontend | Developed using Angular, providing a dynamic and responsive user interface for web-based access to the game. |
| Backend | The backend is implemented in Spring Framework |
| supporting infrastructure | The system uses MongoDB as the primary database. Additionally Apache Kafka is utilized as a messaging system |
To model the domain, the DDD (Domain-Driven Design) approach was applied, complemented by Event Storming. More information: Event Storming
// TODO
// :)
The system integrates Keycloak as the Identity and Access Management (IAM) solution, eliminating the need to develop custom authentication and authorization mechanisms. This choice reduces development effort, enhances security, and ensures compliance with modern authentication standards like OAuth2 and OpenID Connect.
The observability system is designed to provide comprehensive monitoring and troubleshooting capabilities by collecting, processing, and visualizing telemetry data. The core of the system leverages the OpenTelemetry (OTel) Collector to gather signals from various components of the application, including metrics, traces, and logs. All observability data is integrated into Grafana, providing a unified dashboard for:
// TODO
Deployment diagram - dev:
Architecture is described in book: Get Your Hands Dirty on Clean Architecture, by Tom Hombergs.
I have decided to hardcode these values directly into the application because they are highly unlikely to change in the foreseeable future. Additionally, I want to ensure that these values are not cached, as they are used throughout the application and should always remain consistent and readily accessible. This decision carries the risk of requiring manual code modifications if the values need to be updated, which could potentially introduce errors or require additional effort in the future. However, given the current requirements and the expected stability of these values, I consider this trade-off acceptable.
| Term | Definition |
|---|---|
| Tribal Wars | InnoGames game from 2003. |
To model the domain, the DDD (Domain-Driven Design) approach was applied, complemented by Event Storming. Event Storming is an excellent tool for supporting DDD processes, particularly during the exploratory and design phases. It facilitates the identification of domain events, the modeling of business processes, and the development of a shared language among all stakeholders.
Event Storming is created using draw.io, and the corresponding file is located in the designated folder(./f17.drawio).
Below, an exported image of the documentation is provided for reference: